Ext4 (lo que traerá Linux 2.6.28 parte I)

Parte de la documentación de Linux 2.6.28 en el fascista y opresor idioma ejpañol (versión en inglés de este documento).

Ext4 es la evolución del sistema de archivos más utilizado en el mundo Linux, Ext3. En muchos sentidos Ext4 es una mejora más profunda de Ext3 que la que Ext3 fue de Ext2. Ext3 consistió básicamente en añadir journaling, pero Ext4 modifica ciertas estructuras críticas del sistema de archivos, como las destinadas a almacenar los datos de los archivos. El resultado es un sistema de archivos con un diseño mejorado, mayor rendimiento y fiabilidad. Las principales mejoras que ofrece son:

• Compatibilidad: Cualquier sistema de archivos Ext3 existente puede migrarse a Ext4 con un sencillo procedimiento de dos comandos a ejecutar en modo de solo-lectura (procedimiento descrito más adelante). Es decir, que puedes mejorar el rendimiento, límites de almacenamiento y características de un sistema de archivos sin necesidad de reformatear y/o reinstalar tu SO y entorno de software. Si necesitas las ventajas de Ext4 en un entorno de producción, puedes actualizar el sistema de archivos. El procedimiento es sencillo y no pone en riesgo los datos (eso si, se recomienda hacer copia de seguridad de los datos críticos, incluso si no estás actualizandote el sistema de archivos :). Ext4 solamente utilizará sus nuevas estructuras en los nuevos datos que se escriban, los datos antiguos podrán continuar siendo leidos y modificados cuando sea preciso. Esto significa, por supuesto, que una vez que se convierte el sistema de archivos a Ext4, no se puede regresar a Ext3 (aunque hay una posibilidad de montar un sistema de archivos Ext3 con Ext4 de modo que no se utilize el nuevo formato de disco, y así poder volver a montarlo con Ext3, pero así se pierden muchas de las ventajas de Ext4)


• Mayores tamaños del sistema de archivos y de los archivos: Ext3 soporta 16 TB como máximo tamaño del sistema de archivos, y 2 TB de tamaño máximo de cada archivo. Ext4 añade direccionamiento de bloques de 48 bits, y tendrá 1 EB de tamaño máximo de sistema de archivos y 16TB de tamaño máximo de archivo. 1EB = 1.048.576 TB (1EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). ¿Por qué 48 bits, y no 64? Hay algunas limitaciones que necesitan ser solucionadas antes de que Ext4 sea capaz de soportar 64 bits, y esas limitaciones no han sido tratadas en Ext4. Las estructuras de datos de Ext4 han sido diseñadas teniendo esto en mente, de modo que una futura actualización a Ext4 implementará soporte completo de 64 bits. 1EB será suficiente (en serio :) hasta que llegue ese momento. (Nota: el código para crear sistemas de archivo mayores de 16 TB no está presente en ninguna versión estable de e2fsprogs)


• Escalabilidad de subdirectorios: El número máximo de subdirectorios que puede contener un solo directorio en Ext3 es 32.000. Ext4 rompe ese límite y permite un número ilimitado de subdirectorios.


• Extents: Los sistemas de archivo tradicionales derivados de Unix, como Ext3, utilizan un sistema de mapeo de bloques indirecto para llevar cuenta de cada uno de los bloques correspondientes a los datos de un archivo. Este sistema es ineficiente para los archivos grandes, especialmente a la hora de borrarlos o truncarlos, porque el mapeado mantiene una entrada para cada bloque, y los archivos grandes tienen muchos bloques -> mapeados gigantescos cuya manipulación es lenta. Los sistemas de archivo modernos utilizan un sistema distinto llamado "extents". Un extent es básicamente un montón de bloques físicamente contiguis. Básicamente dice: "Los datos están en los próximos n bloques". Por ejemplo, a un archivo de 100 MB puede asignarsele un solo extent de ese tamaño, en vez de tener que crear un mapeado indirecto para 25.600 bloques (4KB por bloque). Los archivos gigantescos son divididos en varios extents. Los extents mejoran el rendimiento y tambien ayudan a reducir la fragmentación, ya que animan a a utilizar rangos continuos en el disco.


• Asignación multibloque: Cuando Ext3 tiene que escribir nuevos datos al disco, hay un asignador de bloques que decide qué bloques libres serán utilizados para escribir esos datos. Pero el asignador de bloques de Ext3 solo puede asignar un bloque (4KB) de una vez. Esto significa que si el sistema necesita escribir los 100 MB de datos mencionados anteriormente, tendrá que llamar al asignador de bloques 25600 (¡y solamente son 100 MB!). No solo esto es muy ineficiente, no permite al asignador optimizar la política de asignación porque no puede saber cuantos datos van a asignarse en total, solo sabe lo de un bloque. Ext4 utiliza un "asignador multibloque" (mballoc), que puede asignas muchos bloques en una sola llamada, en lugar de un bloque por llamada, evitando de ese modo sobrecarga. Esto mejora el rendimiento, y es especialmente útil con asignación diferida y extents. Esta característica no afecta el formato del disco. Tambien hay que tomar nota de que el asignador de bloques/inodos de Ext4 tiene muchas otras mejoras, descritas en detalle en este documento.


• Asignación diferida: La asignación diferida, en inglés delayed allocation, es una mejora de rendimiento (no cambia el formato del disco) que se encuentra en sistemas de archivos modernos como XFS, ZFS, btrfs or Reiser 4; no es una técnica muy expandida por haber sido considerado hasta hace poco como "peligrosa", y que consiste en retrasar la asignación de bloques lo más posible, contrariamente a lo que los sistemas de archivo tradicionales (como Ext3, reiser3, etc) hacen: asignar los bloques tan pronto como es posible. Por ejemplo, si un proceso escribe con write() algo, el sistema de archivos asignará inmediatamente los bloques en los que se colocarán los datos - incluso si los datos no se están escribiendo al disco en ese mismo momento y se van a mantener en el cache algún tiempo. Esta aproximación tiene desventajas. Por ejemplo, cuando un proceso está escribiendo continuamente datos a un archivo que va creciendo, write()s sucesivos asignarán bloques para los datos, pero el sistema de archivos no puede saber si el archivo va a continuar creciendo. Sin embargo, la asignación diferida no asigna los bloques inmediatamente cuando el proceso usa write()s; en vez de eso, difiere la asignación mientras los datos del archivo se mantengan en el cache, hasta que se escriban definitivamente en el disco. Esta aproximación da la oportunidad al asignador de bloques de optimizar la asignación en situaciones en las que el antiguo sistema no podía. La asignación diferida encaja muy bien con las dos anteriormente mencionadas características, extents y asignación multibloque, porque en muchos tipos de carga, cuando el archivo se escribe finalmente al disco, puede asignarse en extents cuya asignación de bloques se ha llevado a cabo con el sistema de asignación multibloque. El rendimiento mejora, y la fragmentación se disminuye en ciertos tipos de carga.


• Fsck rápido: Hacer un fsck es una operación muy lenta, especialmente el primer paso: comprobar todos los inodos del sistema de archivos. En Ext4, al final de cada tabla de grupo de inodos se almacena una lista de inodos no utilizados (junto a un checksum, por seguridad), de modo que el fsck no los comprobará. El resultado es que el tiempo de fsck mejora de 2 a 20 veces, dependiendo del número de inodos utilizados. Hay que notar es fsck, y no Ext4, quien construye la lista de inodos no utilizados. Esto significa que tendrás que pasar un fsck para que se construya la lista de inodos no utilizados, y entonces el próximo fsck será el que sea más rápido (necesitas pasar un fsck para convertir un sistema de archivos Ext3 a Ext4 de todos modos). Hay tambien una característica que toma parte en este aceleramiento del fsck - "flexible block groups" - que tambien acelera las operaciones normales del sistema de archivos.


• Checksumming del Journal: El journal es la parte más utilizada del disco, lo cual hace que los bloques que forman parte de él sean más susceptibles a sufrir un fallo de hardware. Y tratar de recuperar un log de un journal corrupto puede inducir a una corrupción masiva. Ext4 hace un checksum del journal para saber si los bloques del journal están fallando o están corruptos. Pero el checksumming del journal tiene un bonus: permite convertir el sistema de dos fases de Ext3 a una sola fase, acelerando las operaciones del sistema de archivos hasta en un 20% en algunos casos - asi que en este caso se gana fiabilidad y rendimiento al mismo tiempo. (Nota: La parte de esta característica que mejora el rendimiento, el logging asíncrono, está desactivado por defecto y será activado en el futuro)


• Defragmentación en vivo: (Esta característica no está disponible en 2.6.28, pero probablemente lo estará en la próxima versión). Aunque la asignación diferida, los extents y la asignación multibloque ayudan a reducir la fragmentación, con el uso los sistemas de archivos pueden fragmentarse. Por ejemplo: Escribes tres archivos en un mismo directorio y contiguamente en el disco. Algún día necesitas actualizar el archivo del medio, pero el archivo actualizado es un poco más grande, asi que no hay suficiente espacio para él. No queda otra opción que fragmentar el exceso de datos a otro lugar del disco, que causara movimiento de brazo extra en el disco y por tanto pérdida de rendimiento, o tambien puedes asignar para el archivo actualizado espacio contíguo en otro lugar lejano a los otros dos archivos, lo cual causará movimiento de brazo si una aplicación necesita leer todos los archivos de un directorio (por ejemplo, un gestor de archivos creando miniaturas de un directorio lleno de imágenes). Además, el sistema de archivos solo puede ocuparse de ciertos tipos de fragmentación, no puede saber, por ejemplo, que debe mantener todos los archivos relacionados con la carga del SO juntos, porque no sabe qué archivos están relacionados con la carga del SO. Para solventar este problema, Ext4 soporta defragmentación en vivo, y hay una herramienta llamada e4defrag que puede defragmentar archivos individuales o todo el sistema de archivos.


• Características relacionadas con los inodos: inodos más grandes, marcas de tiempo con granularidad de nanosegundos, atributos extendidos rápidos, reserva de inodos...


• Mayores inodos: Ext3 soporta la configurabilidad de los tamaños de inodo (mediante el parámetro -I de mkfs), pero el tamaño de inodo por defecto es de 128 bytes. Ext4 por defecto tendrá 256. Este aumento es necesario para hacer espacio a varios campos extra (como la granularidad de nanosegundos o el versionamiento de inodos), y el tamaño restante del inodo será utilizado para almacenar atributos extendidos que sean lo suficientemente pequeños como para caber en ese espacio. Esto hará que el acceso a esos atributos sea mucho más veloz, lo cual aumenta entre 2 y 7 veces el rendimiento de las aplicaciones que hacen uso de estos atributos extendidos apodados "rápidos".


• Reserva de inodos: La reserva de inodos consiste en reservar varios inodos para futuros archivos cuando se crea un directorio, confiando que serán utilizados en el futuro. Esto mejora el rendimiento, porque cuando los nuevos archivos sean creados en ese directorio podrán usar esos inodos que habían sido reservados. Por tanto, se mejora el rendimiento de la creación y eliminación de archivos.


• Marcas de tiempo con granularidad de nanosegundos: Esto significa que los campos como mtime (modified time) o atime (access time) podrán usar una resolución de nanosegundos, en vez de la que hace uso Ext3, que tan solo alcanza una granularidad a nivel de segundo.


• Preasignación persistente: Esta característica (disponible en Ext3 en las últimas versiones del kernel, y emulada la por glibc de no estar disponible) permite a las aplicaciones preasignar espacio de disco: El sistema de archivos asigna el espacio libre y los bloques necesarios, pero no hay ningún dato en ellos hasta que la aplicación verdaderamente se decida a escribirlos en el futuro. Esto es lo que las aplicaciones P2P hacen cuando preasignan espacio para descargas que tardarán horas o días en completarse, pero implementado con más eficiencia por el sistema de archivos y con una API genérica. Tiene muchos usos: en primer lugar, para evitar que las aplicaciones (como los P2P) lo hagan ellas mismas ineficientemente llenando un archivo de ceros. Segundo, para mejorar la fragmentación, ya que los bloques se asignarán de una sola vez para todo el archivo lo más contiguamente posible. Tercero, para asegurarse de que las aplicaciones tienen el espacio que ellas creen que van a necesitar, lo cual es importante para las aplicaciones tipo RT, ya que sin preasignación el sistema de archivos podría llenarse en la mitad de una operación importante. Esta característica está disponible mediante la interfaz de glibc posix_fallocate().


• Barreras activadas por defecto: Esta opción mejora la integridad del sistema de archivos a costa de algo de rendimiento (se puede desactivar con "mount -o barrier=0", recomendado si estás haciendo benchmarks). De este artículo de LWN: "Antes de escribir el registro de commit [en el journaling], el código del sistema de archivos debe estar totalmente seguro de que todos los datos de las transaciones ha llegado al disco. Escribir los datos al disco en orden no es suficiente; los discos hoy en día tienen grandes caches y reordenarán las operaciones para mejorar el rendimiento. Asi que el sistema de archivos debe ordenar explicitamente al disco que escriba todos los datos del journaling antes de escribir los datos del registro de commit; si el registro de commit se escribe antes, el journal podría corromperse. El subsistema de E/S del kernel facilita esta tarea a travñes del uso de barreras; en esencia, una barrera prohibe la escritura de cualquier bloque tras la barrera, hasta que todos los bloques que se hayan escrito antes de la barrera estén realmente escritos en el disco. Utilizando barreras, los sistemas de archivos pueden estar verdaderamente seguros de que su estructura se mantiene siempre consistente en el disco"

Cómo usar Ext4:

Esta es la primera versión estable de Ext4, asi que aunque todo el desarrollo y lanzamiento final de este sistema de archivos se ha enlentecido y retrasado mucho para garantizar el mismo nivel de estabilidad que podría esperarse de las actuales implementaciones de Ext3, no dejan de aplicarse las mismas reglas que se aplican a todo software ".0".

Algo muy importante que hay que tener en cuenta es que NO hay soporte de Grub para Ext4. Bueno, eso no es del todo cierto: Hay soporte, pero no en las versiones utilizadas por las distros estables. Hay soporte en la rama de desarrollo de GRUB2, pero solo desde este commit. Hay paquetes de grub2 disponibles en Ubuntu y distros derivadas de Debian bajo el nombre "grub-pc". En la rama estable 0.9x, no hay soporte oficial, pero hay un proyecto de Google SoC que lo desarrolló, y Google encuentra parches. Asi que escoje. Las próximas distros basadas en Linux 2.6.28 probablemente tengan el soporte de un modo u otro. La opción segura es dejar tu directorio /boot en una partición Ext3.

Tambien necesitas una version de e2fsprogs actualizada, se recomienda la última versión estable, 1.41.3.

Migrar a Ext4 es muy sencillo. Hay tres métodos diferentes:

• Creando un sistema de archivos desde cero: La opción más fácil, recomendada para las nuevas instalaciones. Simplemente actualiza el paquete e2fsprogs a Ext4, y crea el sistema de archivos normalmente.


• Migrar un sistema de archivos Ext3 existente a Ext4: Tienes que utilizar la herramienta tune2fs en el sistema de archivos deseado, y ese sistema de archivos DEBE estar desmontado. Ejecuta:
  
  # tune2fs -O extents,uninit_bg,dir_index /dev/tusistemadearchivos
  
  Despues de ejecutar esto, DEBES pasarle un fsck. Si no lo haces, Ext4 NO MONTARÁ el sistema de archivos. Este fsck es necesario para devolver el sistema de archivos a un estado consistente. Te dirá que se han encontrado "checksum errors in the group descriptors". Es normal, eso es exactamente lo que tiene que reconstruirse para poder ser montado con Ext4, asi que no te sorprendas al verlos. Dado que para a preguntarte cada vez que encuentra uno de esos fallos, siempre responde que SI. Si no quieres que te pregunte, pásale el parámetro "-p" a fsck, significa "reparación automática":
  
  # fsck -pf /dev/tusistemadearchivos
  
  Hay otra cosa que debe mencionarse. Todos los archivos existentes continuarán utilizando el formato antiguo de mapeo indirecto para mapear todos los bloques de los datos. La herramienta de defragmentación en vivo permitirá migrar cada uno de esos archivos al formato de extents (utilizando una ioctl que ordena al sistema de archivos que reescriba el archivo en el formato de extents; puede utilizarse con seguridad mientras se usa el sistema de archivos con normalidad)


• Montar un sistema de archivos Ext3 con Ext4, sin utilizar, de entre las nuevas características de Ext4, las que cambian el formato del disco. Podrás volver a montar el sistema de archivos con Ext3 de nuevo: Puedes montar un sistema de archivos existente con "mount -t ext4 /dev/tusistemadearchivos /mnt". Hacer esto sin haber hecho el proceso de conversión descrito en el punto de arriba forzará a Ext4 a no utilizar las características nuevas que utilizan el nuevo formato, solamente se utilizarán las características que no lo cambian, como mballoc o la asignación diferida. Se podrá, de este modo, volver a montar el sistema de archivos de nuevo como Ext3. Pero obviamente así te pierdes muchas de las ventajas de Ext4...